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ON A USEFUL FUNCTIONAL REPRESENTATION 
OF CONTROL SYSTEM STRUCTURE 


Harvey L. Malchow 
Charles Stark Draper Laboratory 

An alternative functional structure for control systems is proposed. The 
structure is represented by a three element block diagram and three functional 
definitions. It is argued that the three functional elements form a canonical set. 
The set includes the functions prescription) estimation and control. General 
overlay of the structure on parallel state and nested -it ate control systems is 
discussed. Breakdown of two real nested-state control systems into the proposed 
functional format is displayed. Application of the process to the mapping of 
complex control systems HMD efforts is explained with the Mars Rover Sample 
and Return mission as an example. A previous application of this basic 
functional structure to Space Station performance requirements organisation is 
discussed. 


Introduction 

Many introductory diagrams of feedback control systems have the following 
formatC 1 - 2 . 3 ) 



Fig.l. A Typical Text Feedback Control Loop. 


While this graphic description is economical and nominally correct, it does not 
explicitly display all the necessary functions* generally represented in a controller. 
For example, one problem with Figure 1 from a functional standpoint is that it does 
not explicitly display the estimation function. The feedback loop implicitly returns 
to the control error junction an estimate of the feedback signal. That is, the plant 
feedback signal is operated on by the wire (or by the uncertainty principle in the 


• We draw on the definition given by Pulliam and Price 4 for necessary function 
namely: "... a function is a thing or event that is needed to achieve the mission.” 



most taxing rhetorical case) and so the pure feedback signal originating at the plant 
always arrives corrupted at the summing junction, and is therefore always just an 
estimate whether it is the product of a simple transducer output or the more 
complex product of a filtering process. Gelb 5 defines estimation as the " process of 
extracting information from data Thus in this broad sense, a measurement on 
the plant becomes a state estimate when it is used to compute a state error signal. 
The of the measurement with whatever mapping or filtering is applied, is an 
implicit conversion of measurement data to information, and is therefore, by Gelb’s 
definition, an estimation process. We argue, therefore, that the act of providing a 
feedback estimate is a fundamental and necessary function in control systems** , and 
that this function is always present whether implicitly or explicitly so that 
estimation should be granted canonical functional status. 

We also argue that the act of providing an input to a control system ought to 
have the status of a canonical function. Within the definition of necessary function 
it is therefore argued that no controller can function without an input. Control 
systems are always driven by an input. For regulating systems the input is constant, 
and for Tracking systems it is time dependent. For some systems, for example with 
missile guidance systems and with computer driven machinery, the function of 
prescribing an input state sequence is a complex discipline with sufficient status to 
stand alone as a technical specialty. Takahashi® has argued for inclusion of the input 
function as part of the control system for tracking systems: "If the command signal 
is deterministic in a tracking control problem, a "generator" of the signal is 
considered part of the system." We propose to include inputs to regulating control 
systems as "generators" in the interest of generalization. 

Another problem with Figure 1 is that the signal driving the control box is 
restricted to the difference between the input and the feedback signals. In general, 
the controller operates on a function of the input and feedback signals which is not 
necessarily a simple difference. For example, in the Space Shuttle orbital 
maneuvering system 7 the control actuating signal is driven by a vector cross-product 
(which looks like a differencing driver only for small angles). 


** It may be argued that open loop controllers do not require estimation. However, 
one can counter-argue that the designer always "peeks" to see how the system is 
doing and thereby closes the loop as a living feedback estimator. 


This paper suggests a revised basic functional block diagram for feedback 
control loops based upon the above arguments. The purpose of the revised diagram 
is to create a mental image of feedback control loops that contains the essential 
functions and therefore facilitates structured thinking about control problems. It is 
shown how various examples of working control loops from a variety of applications 
fit within the proposed elemental functional structure. It is then shown how this 
structure can be used to lay out work plans and to organize performance 
requirements matrices for controllers for complex systems. Such systems may have 
many state vectors and modes of operation such as occurs with multi-staged space 
vehicles. 

The Proposed Functional Structure 

We begin by reconstructing Figure 1. If we recognize that in general the 
controller acts upon a function of the comparison between the input and feedback 
states (not necessarily a simple difference), and if we allocate to the controller the 
task of forming that comparison, then the comparison process can be placed inside 
the controller box with the resulting diagram shown in Figure 2. 


input 

CONTROLLER 


PLANT 






4 

i 




Fig. 2 Control Loop With Comparison Junction Inside Controller. 


This form is exhibited for example in Hsu 8 and Cruz 9 . Ogata 10 explicitly displays 
the comparison action inside the controller box. 

The next step is to make the implicit estimation function explicit, and install it 
in the feedback loop. The result is Figure 3. 




input 


CONTROLLER 


PLANT 


ESTIMATOR k 


Fig-3 Control Loop With Estimator Function Installed. 

Many authors use this diagram although some, including Ogata 10 , use the term 
"measuring element" or "measurement" instead of estimator. 

We now take the important step of elevating the input action to function status. 
However before showing the result a few comments are in order. First, in the 
diagrams we have used a personalized noun form (controller and estimator) for the 
functions of control and estimation. The natural implication for the input function 
is therefore that it be termed the "inputer". In the interest of assigning an actual 
word in current usage we substitute the term "prescriber". Usage of this term is not 
without precedent (see for example Kwakernaak 11 and Adams 12 ). Also, the root 
word prescribe has an advantage over other possible choices in that it admits both 
the gerund form prescribing and the action noun form prescription . Secondly, the 
form in which the feedback estimate and the input or prescribed state are entered 
into the control law is mathematically symmetric, i.e. as a difference, cross product, 
or some other symmetric form. To emphasize this symmetry we construct the block 
diagram with the prescriber in symmetric form opposite the controller from the 
estimator. The blocks have equal size to represent the equality of status of the two 
inputs from the standpoint of the controller. The result is Figure 4 which we term 
the "canonical functional form". 







Fig.4 Canonical Functional Feedback Control System. 


The functional blocks represented in Figure 4 are all present in the general linear 
dynamical equation for an undisturbed control system with time dependent input 18 . 


4(O m £(t)q(t) + K,(t)r(t)-K / (t)y(t) 

Here q is the system state, and the left two terms represent the plant dynamics, r(t) 
is the prescribed state, K r is a controller gain, and K f times y is the estimated state 
scaled by a controller gain (i.e., Kf implicitly includes both estimator and controller 
functions). A similar construct is displayed by Franklin and Powell 14 for discrete 
MIMO systems, namely: 

x(k + l) = <Px(k) + rA/r(k)-rKx(/c) 
with r(k) the prescribed state. Since Figure 4 represents all the elements of the 
above equations, we declare the figure to be a necessary and sufficient structure. 


Definitions of the Functions 

It is appropriate at this point to define the elemental functions. We choose the 
point of view of "state control" to facilitate this process. All control systems control 
certain states of the system. The canonical functions must therefore bear some 
association with the states either as inputs to or outputs from the functions. 



Function Definitions 


PRESCRIBER: The PRESCRIBER sets forth desired values of those 
plant states that are controlled by the control system. 

ESTIMATOR: The ESTIMATOR estimates those states that are controlled 
by the control system. 

CONTROLLER: The CONTROLLER compares linear functions of the 
estimated and prescribed states and sends appropriate 
actuation signals to the plant. 

The prescriber defines the purpose of the control system which is to drive the 
plant state to a desired set or sequence of sets of state values. The estimator 
operates on measurements of the plant that are related to the state £ through the 
relationship y = H(x). This equation is inverted to produce a feedback 
proportional to the estimated state. Note that since the closed loop transfer 
function is dimensionless one must have dimensional agreement between the 
prescribed and estimated inputs to the controller. In many systems the controller 
performs a straight state differencing between prescribed and estimated states. 
Gavrilov^ has suggested that control systems involve three internal actions 
including the control action, the monitoring action, and the input action, and that 
structure resembles the one proposed here. However, Gavrilov includes distur- 
bances and measurement noise in the input category, and later qualifies the input 
category of function to include monitoring, which is a definite departure from 
our structure. 

Nested Loops, General Format 

For independent states of a system the overall control system is represented 
simply by an independent set diagrams of the type shown in Figure 4. As stated by 
Meerovi®: "... when there are n controlled variables present, the whole system will 
consist of at least n control loops interconnected in one way or another.". For 
interdependent states as well as time derivatives of the same state one can recast 
Figure 4 in a nested structure. The structure for nested loops depends upon the 


interaction between the controller of one loop and the prescriber of the next. If the 
following prescriber changes its prescribed state as a result of the preceding control 
action (as it might do in Artificial Intelligence systems for example) then the 
structure is applied as drawn in Figure 5a. 



Fig.5a General Nested Loop Structure. 


If the prescribed state is not a function of the preceding control, then the 
preceding control acts as an internal prescriber, and the internal and external 
prescribed states can be added inside the following controller as illustrated in Figure 
5b. 



Fig.5b Nested Loop for Simple External Prescribers. 


Many real control systems such as those shown in the following examples are 
structured as in Figure 5b. 













Examples of Nested Loops 


We display two examples, one involving two nested state vectors, and one 
involving four. The first is a proposed U.S. Space Station flight control system 
structure 17 . The flight control system is responsible for control of (at least) the 
following two state vectors: 1) Space Station attitude, and 2) control moment gyro 
(CMG) stored momentum. The controller for CMG momentum alters the Space 
Station attitude so that gravity gradient torques can unload stored momentum. 
Meanwhile the station attitude controller attempts to maintain alignment with the 
local vertical coordinate frame. In the structure shown in Figure 6, the momentum 
controller output is expected to be the lone dynamic driver of attitude, and the 
external prescribed attitude is constant at some average torque equilibrium value. 
The CMG prescriber declares a desired target CMG momentum which may be 
biased in anticipation of disturbances, and the controller generates a desired attitude 
offset which becomes in essence a prescribed attitude for the attitude controller. 



Fig.6 Two-State Nested Loop Structure for CMG Momentum Management. 


Some schemes 18 weight the CMG momentum controller output, and combine 
that output with a weighted prescribed attitude from the attitude control loop. In 
that case the revised block structure of Figure 6 resembles that of Figure 5a. 

In Figure 7 we display a four-state nested control system 19 for controlling the 
Space Shuttle Orbiter when it is changing its orbital velocity. The highest level state 
vector, representing the outer loop, is the VGO or velocity-to-go vector. 







Fig.7 Four- State Nested Loop System for Space Shuttle Orbital Thrusting. 


VGO is set externally by the VGO prescriber which is part of the Shuttle PEG7 

(Powered Explicit guidance, mode 7) guidance algorithm. VGO is estimated by the 

User Parameter Processor logic which reads IMU data. The estimated VGO is 

* 

compared to the prescribed value in the PEG7 guidance logic which issues an 
appropriate thrust direction command (which we label THR) as long as the VGO 
estimate is sufficiently different than the prescribed VGO . The THR prescriber 
merely prescribes a thrust direction in body coordinates that is through the center of 
mass. The THR estimator feeds back accelerometer data, and the THR controller, 
using "cross product steering" 20 converts the thrust direction error into a body rate 
command. The body attitude rate prescriber prescribes a nominal rate of zero in all 
axes. The rate error is mapped by the rate controller into an Orbital Maneuvering 
System (OMS) engine gimbal deflection command. The OMS deflection prescriber 
presets deflections according to known Shuttle mass distribution. Of the four 
prescriber functions in this example, only the guidance VGO prescriber and the 
OMS deflection prescriber are nontrivial. The others, which are often implicit in 
descriptions of this particular control system, are included in Figure 7 in the interest 
of generality. 

The proposed functional structure allows one to resolve some arguments about 
the meaning of other functional terms used in connection with control systems. For 
example, while " navigation " is clearly an estimation function, the roll of " guidance " 
in flight control systems has been defined by a range of functions. For example 
Blakelock 21 says: 













"The Guidance system performs all the functions of a navigation 
system plus generating the required correction signal to be 
sent to the control system", 
whereas Wolverton 22 is more inclusive: 

"Guidance may be defined as the processes of measurement, data 
extraction and smoothing computation and control which are 
required to assure that a space vehicle reaches a desired 
destination from a given launch point.", 
and Beck 23 is more exclusive: 

"Guidance’s purpose, then is to determine where we want to be 
and how best to get there." 

The first of these definitions has guidance performing an estimation function on 
position ( navigation ) in addition to calculating an error signal (on an unidentified 
state vector). The second definition seems to include estimation and control 
functions, and is notable for its absences of prescriptive function. The third is a 
purely prescriptive function. In the Space Shuttle OMS system, the guidance 
function performs both prescriptive and control tasks according to our definitions. 
It prescribes a VGO . then exercising a control function, tests the prescribed VGO 
against the VGO estimate and issues a control signal to the spacecraft. For Shuttle 
first stage operations however, guidance is a purely prescriptive function 24 , and in 
that case, an attitude sequence is prescribed by extraction from a tabular reference. 
So while " guidance " can be uniquely defined as a prescriptive process, in practice it 
sometimes incorporates the other basic functions. 

Mapping Control Systems 

The stated function structure is useful for systematically identifying control 
system design problem areas. If the canonical functional structure is complete, then 
for each controlled state the basic function set must necessarily be invoked. For a 
complex system then, the overall control problem can be mapped out in a 3 by N 
array, with / = 3 representing the three canonical functions, and N representing the 
controlled states. If a system uses different controllers, estimators, or prescribes 


for different modes of operation, the space of problem areas is expanded to 3 by m 
by N, where m is the number of distinct modes. This structure is illustrated by 
example in Figure 8, where two states are controlled in MODE 1, and three states in 
MODE 2. 


MODE 1 MODE 2 



STATE 1 

STATE 2 

STATE 1 

STATE 2 

STATE 3 

prescribe 


prescribe 


prescribe 


prescribe 


prescribe 






control 


control 

• • • 

control 


control 


control 






estimate 


estimate 


estimate 


estimate 


estimate 


Fig.8 General Control System Mapping Structure. 


Example of a System Structure Map 

As a specific application consider the proposed Mars Rover Sample and Return 
Mission 25 . We begin breaking the problem down by listing flight modes and their 
associated controlled states (those normally associated with flight control - other 
states such as thermal and power control can of course be dealt with in the same 
manner). Table 1 is a hypothetical partial listing which ends at Mars orbit stage 
separation to save space. 
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Table 1. Controlled States for Various Flight Modes. 


flight 

mode: 

Earth 

orbit 

trans-Mars 

boost 

trans-Mars 

coast 

Mars 

deboost 

Mars 

orbit 

stage 

separation 


earth rel 

attitude 

inertial 

attitude 

solar 

attitude 

inertial 

attitude 

Mars rel 
attitude 

relative 

attitude 


earth 

orbit 

inertial 

thrust 

vector 

trans-Mars 
tra jectory 

inertial 

thrust 

vector 

Mars 

Orbit 

relative 

position 

states 

antenna 

pointing 


antenna 

pointing 


antenna 

pointing 

Mars 

attitude 


sol.array 

pointing 


sol.array 

pointing 


sol.array 

pointing 

Mars 

orbit 


CMG 

momentum 


CMG 

momentum 


CMG 

momentum 



We break down the problem areas for column 1 of Table 1 (the Earth orbit 
flight mode) into the task array shown in Figure 9. 


• earth rel 
attitude 

• earth 
orbit 

• antenna 
pointing 

• solar array 
pointing 

• CMG 
momentum 


prescribe 

attitude 

sequence 


prescribe 

appropriate 

orbit 


prescribe 

antenna 

direction 


prescribe 

pointing 

sequence 


prescribe 

CMG 

momentum 










design 

attitude 

controller 


devise orbit 
control 
scheme 


design 
antenna 
j controller 


design 

cooler 


design 

momentum 

manager 










construct 

attitude 

estimator 


design 

navigation 

system 


estimate 

antenna 

pointing 


estimate 

array 

pointing 


measure 

CMG 

momentum 
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Fig.9 Array of Control System Design Tasks for Column 1 of Table 1. 


Some of the problem areas may turn out to be trivial, for example prescribing 
a solar array pointing sequence may just mean stating that the array shall point at 
the sun. However if night-side feathering or differential drag pointing are 
considered this prescriptive function becomes nontrivial. The aim of the general 
process is to be all inclusive at the occasional expense of overkill. 
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Organizing Performance Requirements 

Performance requirements for complex systems are often organized within an 
arbitrarily defined structure. Subsystem designers are asked to submit their 
requirements to the system level designers, and the collection is interleaved in a 
sequence with loose associations. Reference 26 is a case in point. Although the 
report is exhaustive and functionally complete, the flight control system related 
performance requirements are displayed on thirty-odd scattered pages, under a 
dozen different headings, and in some cases, the information is repetitive. 

Using the structures of Figures 8 and 9, and Table 1, it is possible to construct 
organized sets of performance requirements. As demonstrated previously 27 , the 
concepts of control system structure, controlled states, and distinctive operational 
modes lead to the layout of a complete set of place holders into which performance 
requirements may be entered. Table 2 is an example of such a layout that has been 
previously composed 28 for the US Space Station program. 


Table 2. Partial Space Station Performance Requirements Layout. 


II FLIGHT CONTROL fincl.G.N&Cl PERFORMANCE REQUIREMENTS SUMMARY 



attitude 

fdei?) 

attitude rate 
(deg/sec] 

orbit 
(nmi 1 

orbital accel 

(ft's) 

NORMAL 

FLIGHT 

Pres: < 3.99 
Est.:+0.01,3 sigma 

Pres: LVLH +0.02 
Est.: +0.0001 

Pres: 180<alt<250 
inc. = 28.5 deg 
Est.: TBD 

Pres: < 1.0E-05 | 

Est.: 


Cont: +1.0 

Cont: +0.0005 

Cont: TBD 

Cont: 

REBOOST 

Pres: TBD 
Est.: TBD 

Pres: TBD 
Est.: TBD 

Pres: 180<alt<250 
inc. = 28.5 deg 
Est.: TBD 

Pres: TBD 
Est.: TBD 


Cont: TBD 

Cont: TBD 

Cont: TBD 

Cont: TBD 

MRMS OP- 
ERATION 

Pres: TBD 
Est.: TBD 

Pres: TBD 
Est.: TBD 

Pres: 180<alt<250 
inc. = 28.5 deg 
Est.: TBD 

Pres: TBD 
Est.: TBD 


Cont: TBD 

Cont: TBD 

Cont: TBD 

Cont: TBD 

mm 

Pres: TBD 
Est.: TBD 

Pres: TBD 
Est.: TBD 

Pres: 180<alt<250 
inc. = 28.5 deg 
Est.: TBD 

Pres: TBD 
Est.: TBD 


Cont: TBD 

Cont: TBD 

Cont: TBD 

Cont: TBD 

BUILDUP 

Pres: TBD 
Est.: TBD 

Pres: TBD 
Est.: TBD 

Pres: alt>150 
inc. = 28.5 deg 
Est.: TBD 

Pres: TBD 
Est.: TBD 


Cont: TBD 

Cont: TBD 

Cont: TBD 

Cont: TBD 1 

EVA 

Pres: TBD 
Est.: TBD 

Pres: TBD 
Est.: TBD 

Pres: alt>150 
^nc. = 28.5 deg 

Pres: TBD 
Est.: TBD 


Cont: TBD 

Cont: no RCS? 

Cont: 

Cont: 


means 

no req. expected 




















Conclusions 


Control systems, including those that involve many state vectors, can be broken 
down into a three function structure. Identification of this canonical functional 
structure is of practical as well as pedantic value. It allows for a systematic 
mapping out of control system design problem areas, and it provides for 
construction of a complete array of performance requirement place holders. 
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